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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. PPP 
is comprised of three main components: 


1. A method for encapsulating multi-protocol datagrams. 


2. A Link Control Protocol (LCP) for establishing, configuring, 
and testing the data-link connection. 


3. A family of Network Control Protocols (NCPs) for establishing 
and configuring different network-layer protocols. 


This document defines the PPP organization and methodology, and the 
PPP encapsulation, together with an extensible option negotiation 
mechanism which is able to negotiate a rich assortment of 
configuration parameters and provides additional management 
functions. The PPP Link Control Protocol (LCP) is described in terms 
of this mechanism. 


This document is the product of the Point-to-Point Protocol Working 


Group of the Internet Engineering Task Force (IETF). Comments should 
be submitted to the ietf-ppp@ucdavis.edu mailing list. 
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1. Introduction 
Encapsulation 


The PPP encapsulation provides for multiplexing of different 
network-layer protocols simultaneously over the same link. It is 
intended that PPP provide a common solution for easy connection of 
a wide variety of hosts, bridges and routers [1]. 


The PPP encapsulation has been carefully designed to retain 
compatibility with most commonly used supporting hardware. 


Only 8 additional octets are necessary to form the encapsulation 
when used with the default HDLC framing. In environments where 
bandwidth is at a premium, the encapsulation and framing may be 
shortened to 2 or 4 octets. 


To support high speed implementations, the default encapsulation 
uses only simple fields, only one of which needs to be examined 
for demultiplexing. The default header and information fields 
fall on 32-bit boundaries, and the trailer may be padded to an 
arbitrary boundary. 


Link Control Protocol 


In order to be sufficiently versatile to be portable to a wide 
variety of environments, PPP provides a Link Control Protocol 
(LCP). The LCP is used to automatically agree upon the 
encapsulation format options, handle varying limits on sizes of 
packets, authenticate the identity of its peer on the link, 
determine when a link is functioning properly and when it is 
defunct, detect a looped-back link and other common 
misconfiguration errors, and terminate the link. 


Network Control Protocols 


Point-to-Point links tend to exacerbate many problems with the 
current family of network protocols. For instance, assignment and 
management of IP addresses, which is a problem even in LAN 
environments, is especially difficult over circuit-switched 
point-to-point links (such as dial-up modem servers). These 
problems are handled by a family of Network Control Protocols 
(NCPs), which each manage the specific needs required by their 
respective network-layer protocols. These NCPs are defined in 
companion documents. 
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Configuration 


It is intended that PPP links be easy to configure. By design, 
the standard defaults handle all common configurations. The 
implementor can specify improvements to the default configuration, 
which are automatically communicated to the peer without operator 
intervention. Finally, the operator may explicitly configure 
options for the link which enable the link to operate in 
environments where it would otherwise be impossible. 


This self-configuration is implemented through an extensible 
option negotiation mechanism, wherein each end of the link 
describes to the other its capabilities and requirements. 
Although the option negotiation mechanism described in this 
document is specified in terms of the Link Control Protocol (LCP), 
the same facilities are designed to be used by other control 
protocols, especially the family of NCPs. 


1.1 Specification of Requirements 


In this document, several words are used to signify the 
requirements of the specification. These words are often 
capitalized. 


MUST 


This word, or the adjective "required", means that the definition 
is an absolute requirement of the specification. 


MUST NOT 


This phrase means that the definition is an absolute prohibition 
of the specification. 


SHOULD 


This word, or the adjective "recommended", means that there may 
exist valid reasons in particular circumstances to ignore this 
item, but the full implications must be understood and carefully 
weighed before choosing a different course. 


MAY 


This word, or the adjective "optional", means that this item is 
one of an allowed set of alternatives. An implementation which 
does not include this option MUST be prepared to interoperate with 
another implementation which does include the option. 
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1.2 Terminology 
This document frequently uses the following terms: 
datagram 


The unit of transmission in the network layer (such as IP). A 
datagram may be encapsulated in one or more packets passed to the 
data link layer. 


frame 


The unit of transmission at the data link layer. A frame may 
include a header and/or a trailer, along with some number of units 
of data. 


packet 


The basic unit of encapsulation, which is passed across the 
interface between the network layer and the data link layer. A 
packet is usually mapped to a frame; the exceptions are when data 
link layer fragmentation is being performed, or when multiple 
packets are incorporated into a single frame. 


peer 
The other end of the point-to-point link. 

silently discard 
This means the implementation discards the packet without further 
processing. The implementation SHOULD provide the capability of 
logging the error, including the contents of the silently 
discarded packet, and SHOULD record the event in a statistics 
counter. 

2. PPP Encapsulation 
The PPP encapsulation is used to disambiguate multiprotocol 
datagrams. This encapsulation requires framing to indicate the 


beginning and end of the encapsulation. Methods of providing framing 
are specified in companion documents. 
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A summary of the PPP encapsulation is shown below. The fields are 
transmitted from left to right. 


+ 
| 

| 16 bits | * 
+ 


Protocol Field 


The Protocol field is two octets and its value identifies the 
datagram encapsulated in the Information field of the packet. The 
field is transmitted and received most significant octet first. 


The structure of this field is consistent with the ISO 3309 
extension mechanism for address fields. All Protocols MUST be 
odd; the least significant bit of the least significant octet MUST 
equal "1". Also, all Protocols MUST be assigned such that the 
least significant bit of the most significant octet equals "0". 
Frames received which don’t comply with these rules MUST be 
treated as having an unrecognized Protocol. 


Protocol field values in the "0***" to "3***" range identify the 
network-layer protocol of specific packets, and values in the 
"Qx**™ to "b***" range identify packets belonging to the 
associated Network Control Protocols (NCPs), if any. 


Protocol field values in the "4***" to "7***" range are used for 
protocols with low volume traffic which have no associated NCP. 
Protocol field values in the "c***" to "f***" range identify 
packets as link-layer Control Protocols (such as LCP). 


Up-to-date values of the Protocol field are specified in the most 
recent "Assigned Numbers" RFC [2]. Current values are assigned as 


follows: 


Value (in hex) Protocol Name 


0001 Padding Protocol 

0003 to 001f reserved (transparency inefficient) 
0021 Internet Protocol 

0023 OSI Network Layer 

0025 Xerox NS IDP 

0027 DECnet Phase IV 

0029 Appletalk 

002b Novell IPX 

002d Van Jacobson Compressed TCP/IP 
002f Van Jacobson Uncompressed TCP/IP 
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0031 Bridging PDU 

0033 Stream Protocol (ST-II) 

0035 Banyan Vines 

0037 unused 

0039 AppleTalk EDDP 

003b AppleTalk SmartBuffered 

003d Multi-Link 

005d reserved (compression inefficient) 
00cf reserved (PPP NLPID) 

oofa lst choice compression 

ooff reserved (compression inefficient) 
0201 802.1d Hello Packets 

0203 IBM Source Routing BPDU 

0231 Luxcom 

0233 Sigma Network Systems 

8021 Internet Protocol Control Protocol 
8023 OSI Network Layer Control Protocol 
8025 Xerox NS IDP Control Protocol 

8027 DECnet Phase IV Control Protocol 
8029 Appletalk Control Protocol 

802b Novell IPX Control Protocol 

802d Reserved 

802f Reserved 

8031 Bridging NCP 

8033 Stream Protocol Control Protocol 
8035 Banyan Vines Control Protocol 

8037 unused 

8039 Reserved 

803b Reserved 

803d Multi-Link Control Protocol 

80fd Compression Control Protocol 

80ff Reserved 

c021 Link Control Protocol 

c023 Password Authentication Protocol 
c025 Link Quality Report 

e223 Challenge Handshake Authentication Protocol 


Developers of new protocols MUST obtain a number from the Internet 
Assigned Numbers Authority (IANA), at IANA@isi.edu. 


Information Field 
The Information field is zero or more octets. The Information 


field contains the datagram for the protocol specified in the 
Protocol field. 
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The maximum length for the Information field, including Padding, 
is termed the Maximum Receive Unit (MRU), which defaults to 1500 
octets. By negotiation, consenting PPP implementations may use 
other values for the MRU. 


Padding 


On transmission, the Information field MAY be padded with an 
arbitrary number of octets up to the MRU. It is the 
responsibility of each protocol to distinguish padding octets from 
real information. 


3. PPP Link Operation 
3.1 Overview 


In order to establish communications over a point-to-point link, each 
end of the PPP link MUST first send LCP packets to configure and test 
the data link. After the link has been established, the peer MAY be 
authenticated. Then, PPP MUST send NCP packets to choose and 
configure one or more network-layer protocols. Once each of the 
chosen network-layer protocols has been configured, datagrams from 
each network-layer protocol can be sent over the link. 


The link will remain configured for communications until explicit LCP 
or NCP packets close the link down, or until some external event 
occurs (an inactivity timer expires or network administrator 
intervention). 


3.2 Phase Diagram 


In the process of configuring, maintaining and terminating the 
point-to-point link, the PPP link goes through several distinct 


phases: 
4+------ + 4+----------- + 4+-------------- + 
| | UP | | OPENED | | SUCCESS/NONE 
| Dead |------- >| Establish |---------- >| Authenticate |--+ 
| | | | | 
+------ + +----------- + +-------------- + 
a FAIL | FAIL | 
+<-------------- + $---------- + | 
| | | 
| +----------- + | $--------- + | 
| DOWN | | | CLOSING | li. il 
|S====+===8=== Terminate |<---+<---------- Network |<-+ 
4+----------- + 4+--------- + 
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3.3 Link Dead (physical-layer not ready) 


The link necessarily begins and ends with this phase. When an 
external event (such as carrier detection or network administrator 
configuration) indicates that the physical-layer is ready to be used, 
PPP will proceed to the Link Establishment phase. 


During this phase, the LCP automaton (described below) will be in the 
Initial or Starting states. The transition to the Link Establishment 
phase will signal an Up event to the automaton. 


Implementation Note: 


Typically, a link will return to this phase automatically after 
the disconnection of a modem. In the case of a hard-wired line, 
this phase may be extremely short -- merely long enough to detect 
the presence of the device. 


3.4 Link Establishment Phase 


The Link Control Protocol (LCP) is used to establish the connection 
through an exchange of Configure packets. This exchange is complete, 
and the LCP Opened state entered, once a Configure-Ack packet 
(described below) has been both sent and received. 


All Configuration Options are assumed to be at default values unless 
altered by the configuration exchange. See the section on LCP 
Configuration Options for further discussion. 


It is important to note that only Configuration Options which are 
independent of particular network-layer protocols are configured by 
LCP. Configuration of individual network-layer protocols is handled 
by separate Network Control Protocols (NCPs) during the Network-Layer 
Protocol phase. 


Any non-LCP packets received during this phase MUST be silently 
discarded. 


3.5 Authentication Phase 


On some links it may be desirable to require a peer to authenticate 
itself before allowing network-layer protocol packets to be 
exchanged. 


By default, authentication is not mandatory. If an implementation 
desires that the peer authenticate with some specific authentication 
protocol, then it MUST negotiate the use of that authentication 
protocol during Link Establishment phase. 
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Authentication SHOULD take place as soon as possible after link 
establishment. However, link quality determination MAY occur 
concurrently. An implementation MUST NOT allow the exchange of link 
quality determination packets to delay authentication indefinitely. 


Advancement from the Authentication phase to the Network-Layer 

Protocol phase MUST NOT occur until authentication has completed, 
using the negotiated authentication protocol. If authentication 
fails, PPP SHOULD proceed instead to the Link Termination phase. 


Any Network Control Protocol or network-layer protocol packets 
received during this phase MUST be silently discarded. 


3.6 Network-Layer Protocol Phase 


Once PPP has finished the previous phases, each network-layer 
protocol (such as IP, IPX, or AppleTalk) MUST be separately 
configured by the appropriate Network Control Protocol (NCP). 


Each NCP MAY be Opened and Closed at any time. 
Implementation Note: 


Because an implementation may initially use a significant amount 
of time for link quality determination, implementations SHOULD 
avoid fixed timeouts when waiting for their peers to configure a 
NCP. 


After a NCP has reached the Opened state, PPP will carry the 
corresponding network-layer protocol packets. Any network-layer 
protocol packets received when the corresponding NCP is not in the 
Opened state MUST be silently discarded. 


Implementation Note: 
There is an exception to the preceding paragraphs, due to the 
availability of the LCP Protocol-Reject (described below). While 
LCP is in the Opened state, any protocol packet which is 
unsupported by the implementation MUST be returned in a Protocol- 
Reject. Only protocols which are supported are silently 
discarded. 


During this phase, link traffic consists of any possible 
combination of LCP, NCP, and network-layer protocol packets. 


3.7 Link Termination Phase 


PPP can terminate the link at any time. This might happen because of 
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the loss of carrier, authentication failure, link quality failure, 
the expiration of an idle-period timer, or the administrative closing 
of the link. LCP is used to close the link through an exchange of 
Terminate packets. When the link is closing, PPP informs the 
network-layer protocols so that they may take appropriate action. 


After the exchange of Terminate packets, the implementation SHOULD 
signal the physical-layer to disconnect in order to enforce the 
termination of the link, particularly in the case of an 
authentication failure. The sender of the Terminate-Request SHOULD 
disconnect after receiving a Terminate-Ack, or after the Restart 
counter expires. The receiver of a Terminate-Request SHOULD wait for 
the peer to disconnect, and MUST NOT disconnect until at least one 
Restart time has passed after sending a Terminate-Ack. PPP SHOULD 
proceed to the Link Dead phase. 


Any non-LCP packets received during this phase MUST be silently 
discarded. 


Implementation Note: 


The closing of the link by LCP is sufficient. There is no need 
for each NCP to send a flurry of Terminate packets. Conversely, 
the fact that one NCP has Closed is not sufficient reason to cause 
the termination of the PPP link, even if that NCP was the only NCP 
currently in the Opened state. 


The Option Negotiation Automaton 


The finite-state automaton is defined by events, actions and state 
transitions. Events include reception of external commands such as 
Open and Close, expiration of the Restart timer, and reception of 
packets from a peer. Actions include the starting of the Restart 
timer and transmission of packets to the peer. 


Some types of packets -- Configure-Naks and Configure-Rejects, or 
Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and 
Discard-Requests -- are not differentiated in the automaton 
descriptions. As will be described later, these packets do indeed 
serve different functions. However, they always cause the same 
transitions. 


Events Actions 


Up 


Down 
Open 


= lower layer is Up tlu = This-Layer-Up 
lower layer is Down tld This-Layer-Down 
administrative Open tls This-Layer-Started 


Close= administrative Close t1f = This-Layer-Finished 
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= Timeout with counter > 0 irc = Initialize-Restart-Counter 
= Timeout with counter expired zrc = Zero-Restart-Counter 
+ = Receive-Configure-Request (Good) scr = Send-Configure-Request 
- = Receive-Configure-Request (Bad) 
= Receive-Configure-Ack sca = Send-Configure-Ack 
= Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej 
= Receive-Terminate-Request str = Send-Terminate-Request 
= Receive-Terminate-Ack sta = Send-Terminate-Ack 
= Receive-Unknown-Code scj = Send-Code-Reject 
+ = Receive-Code-Reject (permitted) 


or Receive-Protocol-Reject 
- = Receive-Code-Reject (catastrophic) 
or Receive-Protocol-Reject 
= Receive-Echo-Request ser = Send-Echo-Reply 
or Receive-Echo-Reply 
or Receive-Discard-Request 


State Diagram 


The simplified state diagram which follows describes the sequence of 
events for reaching agreement on Configuration Options (opening the 
PPP link) and for later termination of the link. 


This diagram is not a complete representation of the automaton. 
Implementation MUST be done by consulting the actual state transition 
table. 


Events are in upper case. Actions are in lower case. For these 
purposes, the state machine is initially in the Closed state. Once 
the Opened state has been reached, both ends of the link have met the 
requirement of having both sent and received a Configure-Ack packet. 
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RCR TO+ 
+--sta-->+ 4+------- >+ 
| 
ho + RTA +------- + Close  +====537 + 
| |<----- He | |<-str-+<------ | 
[Closed | |Closing| [Opened | 
| Open | | | | 
| | | | | | 
4+------- + 4+------- + +------- + 
| 
+-sca----------------- >+ 
RCN, TO+ V RCR+ RCR- RCA | RCN, TO+ 
+------- >+ 4+------- >+ +--scr-->+ 
| | || 
+------- + TO+ +------- + +------- + 
|<-scr-+<------ | |<-scn-+ | |<----- + 
Req- | | Ack- | | Ack- | 
| Sent | RCA | Reva | | Sent | 
+-sen->| 2s | ------------- > | | +-sca-> | | 
+------- + +------- + +------- + 
RCR- | | RCR+ RCR+ | | RCR- 
| +------------------------------- >+<------- + | 
| | 
4+<------- $ + 
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4.2 State Transition Table 


The complete state transition table follows. States are indicated 
horizontally, and events are read vertically. State transitions and 
actions are represented in the form action/new-state. Multiple 
actions are separated by commas, and may continue on succeeding lines 
as space requires; multiple actions may be implemented in any 
convenient order. The state may be followed by a letter, which 
indicates an explanatory footnote. The dash (’-’) indicates an 
illegal transition. 


| State 
| 0 1 2 3 4 5 
Events | Initial Starting Closed Stopped Closing Stopping 
SS SS +- 
Up | 2 irc,scr/6 - - - - 
Down | - - 0 tls/1 0 1 
Open | tls/1 1 irc,scr/6 3r 5r 5r 
Close | 0 0 2 2 4 4 
TO+ - - - - str/4 str/5 
TO- = - = = t1f/2 t1f/3 
RCR+ | = = sta/2 irc,scr,sca/8 4 5 
RCR- | - - sta/2 irc,scr,scn/6 4 5 
RCA | - - sta/2 sta/3 4 5 
RCN | - - sta/2 sta/3 4 5 
RTR | - - sta/2 sta/3 sta/4 sta/5 
RTA | - - 2 3 tl1f/2 ele73 
RUC | - - scj/2 scj/3 scj/4 scj/5 
RXJ+ = - 2 3 4 5 
RXJ- - = t1f/2 t1f/3 t1lf/2 tit/3 
RXR | - - 2 3 4 5 
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Open 


TO+ 
TO- 


RCR+ 
RCR- 
RCA 
RCN 


RTR 
RTA 


RUC 
RXJ+ 
RXJ- 


— AAA 


The Point-to-Point Protocol 


9 
Opened 


9r 
tld,irc,str/4 


tld, scr,sca/8 
tld, scr,scn/6 
tld, scr/6x 
tld, scr/6x 


tld, zrc,sta/5 
tld, scr/6 


scj/9 
9 
tld, irc,str/5 


State 
6 7 8 
Req-Sent Ack-Rcvd Ack-Sent 
t 1 1 
6 7 8 
Close|irc,str/4 irc,str/4 irc,str/4 
scr/6 scr/6 scr/8 
t1f£/3p t1f£/3p tlf/3p 
sca/8 sca,tlu/9 sca/8 
scn/6 scen/7 scn/6 
irc/7 scr/6x irc,tlu/9 
irc,scr/6 scr/6x irc,scr/8 
sta/6 sta/6 sta/6 
6 6 8 
scj/6 scj/7 scj/8 
6 6 8 
t1f£/3 ELE/3 t1f/3 
6 7 8 


RXR 


ser/9 


December 1993 


The states in which the Restart timer is running are identifiable by 


the presence of TO events. 


Only the Send-Configure-Request, 


Send- 


Terminate-Request and Zero-Restart-Counter actions start or re-start 


the Restart timer. 


[p] 
[r] 


[x] 


Passive option; 


Restart option; 


4.3 A Day in the Life 


The Restart timer is stopped when transitioning 
from any state where the timer is running to a state where the timer 
is not running. 


Crossed connection; 


see Stopped state discussion. 
see Open event discussion. 


see RCA event discussion. 


Here is an example of how a typical implementation might use the 
automaton to implement LCP in a dial-up environment: 


- The Network Access Server is powered on 


phase). 


(Initial state, 


Link Dead 


- A configuration file indicates that a particular link is to be 
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used for PPP access (Open: tls/Starting). The This-Layer-Started 
event turns on DIR to a modem, readying it for accepting calls. 


- An incoming call is answered. The modem CD triggers configuration 
negotiation (Up: irc,scr/Req-Sent, Link Establishment phase). 


- A Configure-Request is received, which is acknowleged (RCR+: 
sca/Ack-Sent). 


- The Request is acknowleged (RCA: irc,tlu/Opened). The This- 
Layer-Up event starts authentication and quality monitoring 
protocols (Authentication phase). 


- When authentication and quality monitoring are satisfied, they 
send an Up event to start the available NCPs (Network-Layer 
Protocol phase). 


- Later, the peer is finished, and closes the link. A Terminate- 
Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). 
The This-Layer-Down action sends the Down event to any NCPs, while 
the Terminate-Ack is sent. The Zero-Restart-Counter action causes 
the link to wait for the peer to process the Terminate-Ack, with 
no retries. 


- When the Restart Timer times out (TO-: tlf/Stopped), the This- 
Layer-Finished action signals the modem to hang up by dropping 
DTR. 

- When the CD from the modem drops (Down: tls/Starting), the This- 
Layer-Started action raises DTR again, readying it for the next 
call (returning to the Link Dead phase). 

4.4 States 
Following is a more detailed description of each automaton state. 
Initial 
In the Initial state, the lower layer is unavailable (Down), and 


no Open has occurred. The Restart timer is not running in the 
Initial state. 


Starting 


The Starting state is the Open counterpart to the Initial state. 
An administrative Open has been initiated, but the lower layer is 
still unavailable (Down). The Restart timer is not running in the 
Starting state. 
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When the lower layer becomes available (Up), a Configure-Request 
is sent. 


Closed 


In the Closed state, the link is available (Up), but no Open has 
occurred. The Restart timer is not running in the Closed state. 


Upon reception of Configure-Request packets, a Terminate-Ack is 
sent. Terminate-Acks are silently discarded to avoid creating a 
loop. 


Stopped 


The Stopped state is the Open counterpart to the Closed state. It 
is entered when the automaton is waiting for a Down event after 
the This-Layer-Finished action, or after sending a Terminate-Ack. 
The Restart timer is not running in the Stopped state. 


Upon reception of Configure-Request packets, an appropriate 
response is sent. Upon reception of other packets, a Terminate- 
Ack is sent. Terminate-Acks are silently discarded to avoid 
creating a loop. 


Rationale: 
The Stopped state is a junction state for link termination, link 


configuration failure, and other automaton failure modes. These 
potentially separate states have been combined. 


There is a race condition between the Down event response (from 
the This-Layer-Finished action) and the Receive-Configure- Request 
event. When a Configure-Request arrives before the Down event, 
the Down event will supercede by returning the automaton to the 
Starting state. This prevents attack by repetition. 


Implementation Option: 


After the peer fails to respond to Configure-Requests, an 
implementation MAY wait passively for the peer to send Configure- 
Requests. In this case, the This-Layer-Finished action is not 
used for the TO- event in states Req-Sent, Ack- Rcvd and Ack-Sent. 


This option is useful for dedicated circuits, or circuits which 


have no status signals available, but SHOULD NOT be used for 
switched circuits. 
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Closing 


In the Closing state, an attempt is made to terminate the 
connection. A Terminate-Request has been sent and the Restart 
timer is running, but a Terminate-Ack has not yet been received. 


Upon reception of a Terminate-Ack, the Closed state is entered. 
Upon the expiration of the Restart timer, a new Terminate-Request 
is transmitted and the Restart timer is restarted. After the 
Restart timer has expired Max-Terminate times, this action may be 
skipped, and the Closed state may be entered. 


Stopping 


The Stopping state is the Open counterpart to the Closing state. 
A Terminate-Request has been sent and the Restart timer is 
running, but a Terminate-Ack has not yet been received. 


Rationale: 
The Stopping state provides a well defined opportunity to 
terminate a link before allowing new traffic. After the link has 


terminated, a new configuration may occur via the Stopped or 
Starting states. 


Request-Sent 
In the Request-Sent state an attempt is made to configure the 
connection. A Configure-Request has been sent and the Restart 


timer is running, but a Configure-Ack has not yet been received 
nor has one been sent. 


Ack-Received 


In the Ack-Received state, a Configure-Request has been sent and a 
Configure-Ack has been received. The Restart timer is still 
running since a Configure-Ack has not yet been sent. 


Ack-Sent 
In the Ack-Sent state, a Configure-Request and a Configure-Ack 


have both been sent but a Configure-Ack has not yet been received. 
The Restart timer is always running in the Ack-Sent state. 


Opened 


In the Opened state, a Configure-Ack has been both sent and 
received. The Restart timer is not running in the Opened state. 
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When entering the Opened state, the implementation SHOULD signal 
the upper layers that it is now Up. Conversely, when leaving the 
Opened state, the implementation SHOULD signal the upper layers 
that it is now Down. 


4.5 Events 
Transitions and actions in the automaton are caused by events. 
Up 


The Up event occurs when a lower layer indicates that it is ready 
to carry packets. 


Typically, this event is used by a modem handling or calling 
process, or by some other coupling of the PPP link to the physical 
media, to signal LCP that the link is entering Link Establishment 
phase. 


It also can be used by LCP to signal each NCP that the link is 
entering Network-Layer Protocol phase. That is, the This-Layer-Up 
action from LCP triggers the Up event in the NCP. 


Down 


The Down event occurs when a lower layer indicates that it is no 
longer ready to carry packets. 


Typically, this event is used by a modem handling or calling 
process, or by some other coupling of the PPP link to the physical 
media, to signal LCP that the link is entering Link Dead phase. 


It also can be used by LCP to signal each NCP that the link is 
leaving Network-Layer Protocol phase. That is, the This-Layer- 
Down action from LCP triggers the Down event in the NCP. 


Open 


The Open event indicates that the link is administratively 
available for traffic; that is, the network administrator (human 
or program) has indicated that the link is allowed to be Opened. 
When this event occurs, and the link is not in the Opened state, 
the automaton attempts to send configuration packets to the peer. 


If the automaton is not able to begin configuration (the lower 


layer is Down, or a previous Close event has not completed), the 
establishment of the link is automatically delayed. 


Simpson [Page 19] 


RFC 1548 The Point-to-Point Protocol December 1993 


When a Terminate-Request is received, or other events occur which 
cause the link to become unavailable, the automaton will progress 
to a state where the link is ready to re-open. No additional 
administrative intervention is necessary. 


Implementation Option: 


Experience has shown that users will execute an additional Open 
command when they want to renegotiate the link. This might 
indicate that new values are to be negotiated. 


Since this is not the meaning of the Open event, it is suggested 
that when an Open user command is executed in the Opened, Closing, 
Stopping, or Stopped states, the implementation issue a Down 
event, immediately followed by an Up event. This will cause the 
renegotiation of the link, without any harmful side effects. 


Close 


The Close event indicates that the link is not available for 
traffic; that is, the network administrator (human or program) has 
indicated that the link is not allowed to be Opened. When this 
event occurs, and the link is not in the Closed state, the 
automaton attempts to terminate the connection. Futher attempts 
to re-configure the link are denied until a new Open event occurs. 


Implementation Note: 


When authentication fails, the link SHOULD be terminated, to 
prevent attack by repetition and denial of service to other users. 
Since the link is administratively available (by definition), this 
can be accomplished by simulating a Close event to the LCP, 
immediately followed by an Open event. 


The Close followed by an Open will cause an orderly termination of 
the link, by progressing from the Closing to the Stopping state, 
and the This-Layer-Finished action can disconnect the link. The 
automaton waits in the Stopped or Starting states for the next 
connection attempt. 


Timeout (TO+,TO-) 
This event indicates the expiration of the Restart timer. The 
Restart timer is used to time responses to Configure-Request and 


Terminate-Request packets. 


The TO+ event indicates that the Restart counter continues to be 
greater than zero, which triggers the corresponding Configure- 
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Request or Terminate-Request packet to be retransmitted. 


The TO- event indicates that the Restart counter is not greater 
than zero, and no more packets need to be retransmitted. 


Receive-Configure-Request (RCR+,RCR-) 


This event occurs when a Configure-Request packet is received from 
the peer. The Configure-Request packet indicates the desire to 


open a connection and may specify Configuration Options. The 
Configure-Request packet is more fully described in a later 
section. 


The RCR+ event indicates that the Configure-Request was 
acceptable, and triggers the transmission of a corresponding 
Configure-Ack. 


The RCR- event indicates that the Configure-Request was 
unacceptable, and triggers the transmission of a corresponding 
Configure-Nak or Configure-Reject. 


Implementation Note: 


These events may occur on a connection which is already in the 
Opened state. The implementation MUST be prepared to immediately 
renegotiate the Configuration Options. 


Receive-Configure-Ack (RCA) 


The Receive-Configure-Ack event occurs when a valid Configure-Ack 
packet is received from the peer. The Configure-Ack packet is a 
positive response to a Configure-Request packet. An out of 
sequence or otherwise invalid packet is silently discarded. 


Implementation Note: 


Since the correct packet has already been received before reaching 
the Ack-Rcvd or Opened states, it is extremely unlikely that 
another such packet will arrive. As specified, all invalid 
Ack/Nak/Rej packets are silently discarded, and do not affect the 
transitions of the automaton. 


However, it is not impossible that a correctly formed packet will 
arrive through a coincidentally-timed cross-connection. It is 
more likely to be the result of an implementation error. At the 
very least, this occurance SHOULD be logged. 
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Receive-Configure-Nak/Rej (RCN) 


This event occurs when a valid Configure-Nak or Configure-Reject 
packet is received from the peer. The Configure-Nak and 
Configure-Reject packets are negative responses to a Configure- 
Request packet. An out of sequence or otherwise invalid packet is 
Silently discarded. 


Implementation Note: 


Although the Configure-Nak and Configure-Reject cause the same 
state transition in the automaton, these packets have 
Significantly different effects on the Configuration Options sent 
in the resulting Configure-Request packet. 


Receive-Terminate-Request (RTR) 


The Receive-Terminate-Request event occurs when a Terminate- 
Request packet is received. The Terminate-Request packet 
indicates the desire of the peer to close the connection. 


Implementation Note: 


This event is not identical to the Close event (see above), and 
does not override the Open commands of the local network 
administrator. The implementation MUST be prepared to receive a 
new Configure-Request without network administrator intervention. 


Receive-Terminate-Ack (RTA) 


The Receive-Terminate-Ack event occurs when a Terminate-Ack packet 
is received from the peer. The Terminate-Ack packet is usually a 
response to a Terminate-Request packet. The Terminate-Ack packet 
may also indicate that the peer is in Closed or Stopped states, 
and serves to re-synchronize the link configuration. 


Receive-Unknown-Code (RUC) 
The Receive-Unknown-Code event occurs when an un-interpretable 
packet is received from the peer. A Code-Reject packet is sent in 
response. 


Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) 


This event occurs when a Code-Reject or a Protocol-Reject packet 
is received from the peer. 


The RXJ+ event arises when the rejected value is acceptable, such 
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as a Code-Reject of an extended code, or a Protocol-Reject of a 
NCP. These are within the scope of normal operation. The 
implementation MUST stop sending the offending packet type. 


The RXJ- event arises when the rejected value is catastrophic, 
such as a Code-Reject of Configure-Request, or a Protocol-Reject 
of LCP! This event communicates an unrecoverable error that 
terminates the connection. 


Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request 
(RXR) 


This event occurs when an Echo-Request, Echo-Reply or Discard- 
Request packet is received from the peer. The Echo-Reply packet is 
a response to a Echo-Request packet. There is no reply to an Echo- 
Reply or Discard-Request packet. 


4.6 Actions 


Actions in the automaton are caused by events and typically indicate 
the transmission of packets and/or the starting or stopping of the 
Restart timer. 


Illegal-Event (-) 


This indicates an event that cannot occur in a properly 
implemented automaton. The implementation has an internal error, 
which should be reported and logged. No transition is taken, and 
the implementation SHOULD NOT reset or freeze. 


This-Layer-Up (tlu) 


This action indicates to the upper layers that the automaton is 
entering the Opened state. 


Typically, this action is used by the LCP to signal the Up event 
to a NCP, Authentication Protocol, or Link Quality Protocol, or 
MAY be used by a NCP to indicate that the link is available for 
its network layer traffic. 


This-Layer-Down (tld) 


This action indicates to the upper layers that the automaton is 
leaving the Opened state. 


Typically, this action is used by the LCP to signal the Down event 


to a NCP, Authentication Protocol, or Link Quality Protocol, or 
MAY be used by a NCP to indicate that the link is no longer 
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available for its network layer traffic. 
This-Layer-Started (tls) 


This action indicates to the lower layers that the automaton is 
entering the Starting state, and the lower layer is needed for the 
link. The lower layer SHOULD respond with an Up event when the 
lower layer is available. 


Implementation Note: 
This results of this action are highly implementation dependent. 


The transitions where this event is indicated are defined 
according to a message passing architecture, rather than a 
signalling architecture. If the action is desired to control 
specific signals (such as DTR), other transitions for the action 
are likely to be required (Open in Closed, RCR in Stopped). 


This-Layer-Finished (tlf) 


This action indicates to the lower layers that the automaton is 
entering the Stopped or Closed states, and the lower layer is no 
longer needed for the link. The lower layer SHOULD respond with a 
Down event when the lower layer has terminated. 


Typically, this action MAY be used by the LCP to advance to the 
Link Dead phase, or MAY be used by a NCP to indicate to the LCP 
that the link may terminate when there are no other NCPs open. 


Implementation Note: 
This results of this action are highly implementation dependent. 
The transitions where this event is indicated are defined 
according to a message passing architecture, rather than a 
signalling architecture. If the action is desired to control 
specific signals (such as DTR), other transitions for the action 
are likely to be required (Close in Starting, Down in Closing). 
Initialize-Restart-Counter (irc) 
This action sets the Restart counter to the appropriate value 


(Max-Terminate or Max-Configure). The counter is decremented for 
each transmission, including the first. 
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Implementation Note: 


In addition to setting the Restart counter, the implementation 
MUST set the timeout period to the initial value when Restart 
timer backoff is used. 


Zero-Restart-Counter (zrc) 
This action sets the Restart counter to zero. 
Implementation Note: 


This action enables the FSA to pause before proceeding to the 
desired final state, allowing traffic to be processed by the peer. 
In addition to zeroing the Restart counter, the implementation 
MUST set the timeout period to an appropriate value. 


Send-Configure-Request (scr) 


The Send-Configure-Request action transmits a Configure-Request 
packet. This indicates the desire to open a connection with a 
specified set of Configuration Options. The Restart timer is 
started when the Configure-Request packet is transmitted, to guard 
against packet loss. The Restart counter is decremented each time 
a Configure-Request is sent. 


Send-Configure-Ack (sca) 


The Send-Configure-Ack action transmits a Configure-Ack packet. 
This acknowledges the reception of a Configure-Request packet with 
an acceptable set of Configuration Options. 


Send-Configure-Nak (scn) 


The Send-Configure-Nak action transmits a Configure-Nak or 
Configure-Reject packet, as appropriate. This negative response 
reports the reception of a Configure-Request packet with an 
unacceptable set of Configuration Options. Configure-Nak packets 
are used to refuse a Configuration Option value, and to suggest a 
new, acceptable value. Configure-Reject packets are used to 
refuse all negotiation about a Configuration Option, typically 
because it is not recognized or implemented. The use of 
Configure-Nak versus Configure-Reject is more fully described in 
the section on LCP Packet Formats. 


Send-Terminate-Request (str) 


The Send-Terminate-Request action transmits a Terminate-Request 
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packet. This indicates the desire to close a connection. The 
Restart timer is started when the Terminate-Request packet is 
transmitted, to guard against packet loss. The Restart counter is 
decremented each time a Terminate-Request is sent. 


Send-Terminate-Ack (sta) 


The Send-Terminate-Ack action transmits a Terminate-Ack packet. 
This acknowledges the reception of a Terminate-Request packet or 
otherwise serves to synchronize the state machines. 


Send-Code-Reject (scj) 


The Send-Code-Reject action transmits a Code-Reject packet. This 
indicates the reception of an unknown type of packet. 


Send-Echo-Reply (ser) 


The Send-Echo-Reply action transmits an Echo-Reply packet. This 
acknowledges the reception of an Echo-Request packet. 


4.7 Loop Avoidance 


The protocol makes a reasonable attempt at avoiding Configuration 
Option negotiation loops. However, the protocol does NOT guarantee 
that loops will not happen. As with any negotiation, it is possible 
to configure two PPP implementations with conflicting policies that 
will never converge. It is also possible to configure policies which 
do converge, but which take significant time to do so. Implementors 
should keep this in mind and SHOULD implement loop detection 
mechanisms or higher level timeouts. 


4.8 Counters and Timers 


Restart Timer 


There is one special timer used by the automaton. The Restart 
timer is used to time transmissions of Configure-Request and 


Terminate- Request packets. Expiration of the Restart timer 
causes a Timeout event, and retransmission of the corresponding 
Configure-Request or Terminate-Request packet. The Restart timer 


MUST be configurable, but SHOULD default to three (3) seconds. 


Implementation Note: 


The Restart timer SHOULD be based on the speed of the link. The 
default value is designed for low speed (2,400 to 9,600 bps), high 
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switching latency links (typical telephone lines). Higher speed 
links, or links with low switching latency, SHOULD have 
correspondingly faster retransmission times. 


Instead of a constant value, the Restart timer MAY begin at an 
initial small value and increase to the configured final value. 
Each successive value less than the final value SHOULD be at least 
twice the previous value. The initial value SHOULD be large 
enough to account for the size of the packets, twice the round 
trip time for transmission at the link speed, and at least an 
additional 100 milliseconds to allow the peer to process the 
packets before responding. Some circuits add another 200 
milliseconds of satellite delay. Round trip times for modems 
operating at 14,400 bps have been measured in the range of 160 to 
more than 600 milliseconds. 


Max-Terminate 


There is one required restart counter for Terminate-Requests. 
Max- Terminate indicates the number of Terminate-Request packets 
sent without receiving a Terminate-Ack before assuming that the 
peer is unable to respond. Max-Terminate MUST be configurable, 
but SHOULD default to two (2) transmissions. 


Max-Configure 


A similar counter is recommended for Configure-Requests. Max- 
Configure indicates the number of Configure-Request packets sent 
without receiving a valid Configure-Ack, Configure-Nak or 
Configure- Reject before assuming that the peer is unable to 
respond. Max- Configure MUST be configurable, but SHOULD default 
to ten (10) transmissions. 


Max-Failure 


A related counter is recommended for Configure-Nak. Max-Failure 
indicates the number of Configure-Nak packets sent without sending 
a Configure-Ack before assuming that configuration is not 
converging. Any further Configure-Nak packets are converted to 
Configure-Reject packets. Max-Failure MUST be configurable, but 
SHOULD default to ten (10) transmissions. 


5. LCP Packet Formats 
There are three classes of LCP packets: 


1. Link Configuration packets used to establish and configure a 
link (Configure-Request, Configure-Ack, Configure-Nak and 
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Configure-Reject). 


2. Link Termination packets used to terminate a link (Terminate- 
Request and Terminate-Ack). 


3. Link Maintenance packets used to manage and debug a link 
(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and 
Discard-Request). 


This document describes Version 1 of the Link Control Protocol. In 
the interest of simplicity, there is no version field in the LCP 
packet. If a new version of LCP is necessary in the future, the 
intention is that a new PPP Protocol field value will be used to 
differentiate Version 1 LCP from all other versions. A correctly 
functioning Version 1 LCP implementation will always respond to 
unknown Protocols (including other versions) with an easily 
recognizable Version 1 packet, thus providing a deterministic 
fallback mechanism for implementations of other versions. 


Regardless of which Configuration Options are enabled, all LCP Link 
Configuration, Link Termination, and Code-Reject packets (codes 1 
through 7) are always sent as if no Configuration Options were 
enabled. This ensures that such LCP packets are always recognizable 
even when one end of the link mistakenly believes the link to be 
open. 


Implementation Note: 


In particular, the Async-Control-Character-Map (ACCM) default for 
the type of link is used, and no address, control, or protocol 
field compression is allowed. 


Exactly one LCP packet is encapsulated in the PPP Information 
field, where the PPP Protocol field indicates type hex c021 (Link 
Control Protocol). 


A summary of the Link Control Protocol packet format is shown below. 
The fields are transmitted from left to right. 


0 a 2 3 
0 1-2-3496. 7 8-9-0. 12.34.56 7-8 9:0:1-23 405.617.890 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Data 

+-+-+-+-+ 
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Code 


The Code field is one octet and identifies the kind of LCP packet. 
When a packet is received with an invalid Code field, a Code- 
Reject packet is transmitted. 


Up-to-date values of the LCP Code field are specified in the most 
recent "Assigned Numbers" RFC [2]. This specification concerns 
the following values: 


Configure-Request 
Configure-Ack 
Configure-Nak 
Configure-Reject 
Terminate-Request 
Terminate-Ack 
Code-Reject 
Protocol-Reject 
Echo-Request 

0 Echo-Reply 

1 Discard-Request 


RRP0O0O JAÉN 


Identifier 
The Identifier field is one octet and aids in matching requests 
and replies. When a packet is received with an invalid Identifier 
field, the packet is silently discarded. 

Length 
The Length field is two octets and indicates the length of the LCP 
packet including the Code, Identifier, Length and Data fields. 
Octets outside the range of the Length field are treated as 
padding and are ignored on reception. When a packet is received 
with an invalid Length field, the packet is silently discarded. 

Data 
The Data field is zero or more octets as indicated by the Length 
field. The format of the Data field is determined by the Code 
field. 

5.1 Configure-Request 


Description 


An implementation wishing to open a connection MUST transmit a LCP 
packet with the Code field set to 1 (Configure-Request), and the 
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Options field filled with any desired changes to the link 
defaults. Configuration Options SHOULD NOT be included with 
default values. 


Upon reception of a Configure-Request, an appropriate reply MUST 
be transmitted. 


A summary of the Configure-Request packet format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 
O12 3: AP 9 00 1 8,9000 1.2 3 Pb o PB Ge 0 1 2 SA O 6 EB 0300; A 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
dh A O O A O O A +H 
| Options 


++ + +4 
Code 
1 for Configure-Request. 


Identifier 


The Identifier field MUST be changed whenever the content of the 
Options field changes, and whenever a valid reply has been 
received for a previous request. For retransmissions, the 
Identifier MAY remain unchanged. 


Options 


The options field is variable in length and contains the list of 
zero or more Configuration Options that the sender desires to 
negotiate. All Configuration Options are always negotiated 
simultaneously. The format of Configuration Options is further 
described in a later section. 


5.2 Configure-Ack 


Description 


If every Configuration Option received in a Configure-Request is 
recognizable and all values are acceptable, then the 
implementation MUST transmit a LCP packet with the Code field set 
to 2 (Configure-Ack), the Identifier field copied from the 
received Configure-Request, and the Options field copied from the 
received Configure-Request. The acknowledged Configuration 
Options MUST NOT be reordered or modified in any way. 
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On reception of a Configure-Ack, the Identifier field MUST match 
that of the last transmitted Configure-Request. Additionally, the 
Configuration Options in a Configure-Ack MUST exactly match those 
of the last transmitted Configure-Request. Invalid packets are 
Silently discarded. 


A summary of the Configure-Ack packet format is shown below. The 
fields are transmitted from left to right. 


0 a 2 3 
0T 2S ADO BOLA A Os TBs OOM Le 28 3 AP On 67-1 B= Oe Oe AL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Options 

+-4+-+-+-+ 


Code 
2 for Configure-Ack. 


Identifier 


The Identifier field is a copy of the Identifier field of the 
Configure-Request which caused this Configure-Ack. 


Options 


The Options field is variable in length and contains the list of 
zero or more Configuration Options that the sender is 
acknowledging. All Configuration Options are always acknowledged 
simultaneously. 


5.3 Configure-Nak 
Description 


If every element of the received Configuration Options is 
recognizable but some values are not acceptable, then the 
implementation MUST transmit a LCP packet with the Code field set 
to 3 (Configure-Nak), the Identifier field copied from the 
received Configure-Request, and the Options field filled with only 
the unacceptable Configuration Options from the Configure-Request. 
All acceptable Configuration Options are filtered out of the 
Configure-Nak, but otherwise the Configuration Options from the 
Configure-Request MUST NOT be reordered. 


Options which have no value fields (boolean options) MUST use the 
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Configure-Reject reply instead. 


Each Configuration Option which is allowed only a single instance 
MUST be modified to a value acceptable to the Configure-Nak 
sender. The default value MAY be used, when this differs from the 
requested value. 


When a particular type of Configuration Option can be listed more 
than once with different values, the Configure-Nak MUST include a 
list of all values for that option which are acceptable to the 
Configure-Nak sender. This includes acceptable values that were 
present in the Configure-Request. 


Finally, an implementation may be configured to request the 
negotiation of a specific Configuration Option. If that option is 
not listed, then that option MAY be appended to the list of Nak’d 
Configuration Options in order to prompt the peer to include that 
option in its next Configure-Request packet. Any value fields for 
the option MUST indicate values acceptable to the Configure-Nak 
sender. 


On reception of a Configure-Nak, the Identifier field MUST match 
that of the last transmitted Configure-Request. Invalid packets 
are silently discarded. 


Reception of a valid Configure-Nak indicates that a new 
Configure-Request MAY be sent with the Configuration Options 
modified as specified in the Configure-Nak. When multiple 
instances of a Configuration Option are present, the peer SHOULD 
select a single value to include in its next Configure-Request 
packet. 


Some Configuration Options have a variable length. Since the 
Nak’d Option has been modified by the peer, the implementation 
MUST be able to handle an Option length which is different from 
the original Configure-Request. 


A summary of the Configure-Nak packet format is shown below. The 
fields are transmitted from left to right. 


0 I 2 3 
Oe 2 AO Oe BO e238 AO 6 IB Ge Oo ZAS AO 6. rO L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+- ++ 
| Options 

+-4+-+-+-+ 
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Code 
3 for Configure-Nak. 
Identifier 


The Identifier field is a copy of the Identifier field of the 
Configure-Request which caused this Configure-Nak. 


Options 


The Options field is variable in length and contains the list of 
zero or more Configuration Options that the sender is Nak'ing. 
All Configuration Options are always Nak’d simultaneously. 


5.4 Configure-Reject 
Description 


If some Configuration Options received in a Configure-Request are 
not recognizable or are not acceptable for negotiation (as 
configured by a network administrator), then the implementation 
MUST transmit a LCP packet with the Code field set to 4 
(Configure-Reject), the Identifier field copied from the received 
Configure-Request, and the Options field filled with only the 
unacceptable Configuration Options from the Configure-Request. 

All recognizable and negotiable Configuration Options are filtered 
out of the Configure-Reject, but otherwise the Configuration 
Options MUST NOT be reordered or modified in any way. 


On reception of a Configure-Reject, the Identifier field MUST 
match that of the last transmitted Configure-Request. 
Additionally, the Configuration Options in a Configure-Reject MUST 
be a proper subset of those in the last transmitted Configure- 
Request. Invalid packets are silently discarded. 


Reception of a valid Configure-Reject indicates that a new 
Configure-Request SHOULD be sent which does not include any of the 


Configuration Options listed in the Configure-Reject. 


A summary of the Configure-Reject packet format is shown below. The 
fields are transmitted from left to right. 
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0 1 2 3 
OQ L239 4976-7 8 9:00.1.:2 3.4.5 67.89.00 Le 23) 436.77 8-9 Or 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Options 
+-+-+-+-+ 

Code 


4 for Configure-Reject. 
Identifier 


The Identifier field is a copy of the Identifier field of the 
Configure-Request which caused this Configure-Reject. 


Options 


The Options field is variable in length and contains the list of 
zero or more Configuration Options that the sender is rejecting. 
All Configuration Options are always rejected simultaneously. 


5.5 Terminate-Request and Terminate-Ack 
Description 


LCP includes Terminate-Request and Terminate-Ack Codes in order to 
provide a mechanism for closing a connection. 


A LCP implementation wishing to close a connection SHOULD transmit 
a LCP packet with the Code field set to 5 (Terminate-Request), and 
the Data field filled with any desired data. Terminate-Request 
packets SHOULD continue to be sent until Terminate-Ack is 
received, the lower layer indicates that it has gone down, or a 
sufficiently large number have been transmitted such that the peer 
is down with reasonable certainty. 


Upon reception of a Terminate-Request, a LCP packet MUST be 
transmitted with the Code field set to 6 (Terminate-Ack), the 
Identifier field copied from the Terminate-Request packet, and the 
Data field filled with any desired data. 


Reception of an unelicited Terminate-Ack indicates that the peer 
is in the Closed or Stopped states, or is otherwise in need of 


re-negotiation. 


A summary of the Terminate-Request and Terminate-Ack packet formats 
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is shown below. The fields are transmitted from left to right. 


0 1 2 3 
0 12-34-96. 7:8-9:.0.1.2.34.5 67-86 9:0:1-2.3 405.617.890 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Data 


+-+-+-+-+ 
Code 
5 for Terminate-Request; 
6 for Terminate-Ack. 


Identifier 


On transmission, the Identifier field MUST be changed whenever the 
content of the Data field changes, and whenever a valid reply has 
been received for a previous request. For retransmissions, the 
Identifier MAY remain unchanged. On reception, the Identifier 
field of the Terminate-Request is copied into the Identifier field 
of the Terminate-Ack packet. 


Data 


The Data field is zero or more octets and contains uninterpreted 
data for use by the sender. The data may consist of any binary 


value and may be of any length from zero to the peer’s established 
MRU minus four. 


5.6 Code-Reject 


Description 


Reception of a LCP packet with an unknown Code indicates that one 
of the communicating LCP implementations is faulty or incomplete. 
This error MUST be reported back to the sender of the unknown Code 
by transmitting a LCP packet with the Code field set to 7 (Code- 
Reject), and the inducing packet copied to the Rejected- 
Information field. 


Upon reception of a Code-Reject, the implementation SHOULD report 
the error, since it is unlikely that the situation can be 
rectified automatically. 
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A summary of the Code-Reject packet format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 

O A 2 3425: 6: T g 9 OT 23 A 6.7890, 1:23 45 67-890. 1 
dh + tata q tata tata tata tata ta ++ + + ++ + ++ ++ +++ +++ 
| Code | Identifier | Length 
dh + hh dd e + dd + + + + + ++ ++ +++ ++ +++ +++ ++ 
| Rejected-Packet 
+-+-+-+-+-+-+-+-+ 


Code 

7 for Code-Reject. 
Identifier 

The Identifier field MUST be changed for each Code-Reject sent. 
Rejected-Information 


The Rejected-Information field contains a copy of the LCP packet 
which is being rejected. It begins with the Information field, 
and does not include any Data Link Layer headers nor an FCS. The 
Rejected-Information MUST be truncated to comply with the peer’s 
established MRU. 


5.7 Protocol-Reject 
Description 


Reception of a PPP packet with an unknown Protocol field indicates 
that the peer is attempting to use a protocol which is 
unsupported. This usually occurs when the peer attempts to 
configure a new protocol. If the LCP state machine is in the 
Opened state, then this error MUST be reported back to the peer by 
transmitting a LCP packet with the Code field set to 8 (Protocol- 
Reject), the Rejected-Protocol field set to the received Protocol, 
and the inducing packet copied to the Rejected-Information field. 


Upon reception of a Protocol-Reject, the implementation MUST stop 
sending packets of the indicated protocol at the earliest 
opportunity. 


Protocol-Reject packets can only be sent in the LCP Opened state. 


Protocol-Reject packets received in any state other than the LCP 
Opened state SHOULD be silently discarded. 
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A summary of the Protocol-Reject packet format is shown below. The 
fields are transmitted from left to right. 


0 dl 2 3 
O AZ A Oe BO e238 AO 6 IB O D2 3A, 890 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Code | Identifier | Length 
dh + Ph q E hd e + + + +++ 
| Rejected-Protocol | Rejected-Information 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Code 
8 for Protocol-Reject. 
Identifier 


The Identifier field MUST be changed for each Protocol-Reject 
sent. 


Rejected-Protocol 


The Rejected-Protocol field is two octets and contains the PPP 
Protocol field of the packet which is being rejected. 


Rejected-Information 


The Rejected-Information field contains a copy of the packet which 
is being rejected. It begins with the Information field, and does 
not include any Data Link Layer headers nor an FCS. The 
Rejected-Information MUST be truncated to comply with the peer’s 
established MRU. 


5.8 Echo-Request and Echo-Reply 
Description 


LCP includes Echo-Request and Echo-Reply Codes in order to provide 
a Data Link Layer loopback mechanism for use in exercising both 
directions of the link. This is useful as an aid in debugging, 
link quality determination, performance testing, and for numerous 
other functions. 


An Echo-Request sender transmits a LCP packet with the Code field 
set to 9 (Echo-Request), the Identifier field set, the local 
Magic-Number (if any) inserted, and the Data field filled with any 
desired data, but not exceeding the peer’s established MRU minus 
eight. 
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Upon reception of an Echo-Request, a LCP packet MUST be 
transmitted with the Code field set to 10 (Echo-Reply), the 
Identifier field copied from the received Echo-Request, the local 
Magic-Number (if any) inserted, and the Data field copied from the 
Echo-Request, truncating as necessary to avoid exceeding the 
peer's established MRU. 


Echo-Request and Echo-Reply packets may only be sent in the LCP 
Opened state. Echo-Request and Echo-Reply packets received in any 
state other than the LCP Opened state SHOULD be silently 
discarded. 


A summary of the Echo-Request and Echo-Reply packet formats is shown 
below. The fields are transmitted from left to right. 


0 dt 2 3 

0 I 23) 4-56: 7 8-9:00-1 234 86 1 89-0 1 23345 6 7 8 9:01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++ A ++ 
| Code | Identifier | Length 
HA A AAA A O O O O A A A A O O O O A A A A o A A A A ++ 
| Magic-Number | 
foto to to tatatatatoto toto tata tatatitototo ta tatatatititototetetatat 
| Data 
+-+-+-+-+ 


Code 
9 for Echo-Request; 
10 for Echo-Reply. 

Identifier 
On transmission, the Identifier field MUST be changed whenever the 
content of the Data field changes, and whenever a valid reply has 
been received for a previous request. For retransmissions, the 


Identifier MAY remain unchanged. 


On reception, the Identifier field of the Echo-Request is copied 
into the Identifier field of the Echo-Reply packet. 


Magic-Number 


The Magic-Number field is four octets and aids in detecting links 
which are in the looped-back condition. Until the Magic-Number 
Configuration Option has been successfully negotiated, the Magic- 
Number MUST be transmitted as zero. See the Magic-Number 
Configuration Option for further explanation. 
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Data 


The Data field is zero or more octets and contains uninterpreted 
data for use by the sender. The data may consist of any binary 
value and may be of any length from zero to the peer’s established 
MRU minus eight. 


5.9 Discard-Request 
Description 


LCP includes a Discard-Request Code in order to provide a Data 
Link Layer sink mechanism for use in exercising the local to 
remote direction of the link. This is useful as an aid in 
debugging, performance testing, and for numerous other functions. 


The sender transmits a LCP packet with the Code field set to 11 
(Discard-Request), the Identifier field set, the local Magic- 
Number (if any) inserted, and the Data field filled with any 
desired data, but not exceeding the peer’s established MRU minus 
eight. 


Discard-Request packets may only be sent in the LCP Opened state. 
On reception, the receiver MUST simply throw away any Discard- 
Request that it receives. 


A summary of the Discard-Request packet format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 

Oo TD 203° O BOLA SAO PB CO OL, LS ADO 9" OE 
Hato AAA O toto O AO A A A O O ta O A A A A A ++ 
| Code | Identifier | Length 
HA AO AO A A A O O O O AO A A A O O O O A A A A A A A A + + 
| Magic-Number | 
O 
| Data 
+-+-+-+-+ 


Code 
11 for Discard-Request. 


Identifier 


The Identifier field MUST be changed for each Discard-Request 
sent. 
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Magic-Number 


The Magic-Number field is four octets and aids in detecting links 
which are in the looped-back condition. Until the Magic-Number 
Configuration Option has been successfully negotiated, the Magic- 
Number MUST be transmitted as zero. See the Magic-Number 
Configuration Option for further explanation. 


Data 


The Data field is zero or more octets and contains uninterpreted 
data for use by the sender. The data may consist of any binary 
value and may be of any length from zero to the peer's established 
MRU minus four. 


6. LCP Configuration Options 


LCP Configuration Options allow negotiation of modifications to the 
default characteristics of a point-to-point link. If a Configuration 
Option is not included in a Configure-Request packet, the default 
value for that Configuration Option is assumed. 


Some Configuration Options MAY be listed more than once. The effect 
of this is Configuration Option specific, and is specified by each 
such Configuration Option description. (None of the Configuration 
Options in this specification can be listed more than once.) 


The end of the list of Configuration Options is indicated by the 
length of the LCP packet. 


Unless otherwise specified, all Configuration Options apply in a 
half-duplex fashion; typically, in the receive direction of the link 
from the point of view of the Configure-Request sender. 


A summary of the Configuration Option format is shown below. The 
fields are transmitted from left to right. 


0 1 

00122 SA AO 8-908 LL Bi AS: TEO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
The Type field is one octet and indicates the type of 


Configuration Option. Up-to-date values of the LCP Option Type 
field are specified in the most recent "Assigned Numbers" RFC [2]. 
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This specification concerns the following values: 


Maximum-Receive-Unit 
Async-Control-Character-Map 
Authentication-Protocol 
Quality-Protocol 

Magic-Number 

RESERVED 

Protocol-Field-Compression 
Address-and-Control-Field-Compression 


073004 0NnNRe 


Length 


The Length field is one octet and indicates the length of this 
Configuration Option including the Type, Length and Data fields. 
If a negotiable Configuration Option is received in a Configure- 
Request but with an invalid Length, a Configure-Nak SHOULD be 
transmitted which includes the desired Configuration Option with 
an appropriate Length and Data. 


Data 


The Data field is zero or more octets and information specific to 
the Configuration Option. The format and length of the Data field 
is determined by the Type and Length fields. 


6.1 Maximum-Receive-Unit 
Description 


This Configuration Option may be sent to inform the peer that the 
implementation can receive larger packets, or to request that the 
peer send smaller packets. 


The default value is 1500 octets. If smaller packets are 
requested, an implementation MUST still be able to receive the 
full 1500 octet information field in case link synchronization is 
lost. 


Implementation Note: 


This option is used to indicate an implementation capability. The 
peer is not required to maximize the use of the capacity. For 
example, when a MRU is indicated which is 2048 octets, the peer is 
not required to send any packet with 2048 octets. The peer need 
not Configure-Nak to indicate that it will only send smaller 
packets, since the implementation will always require support for 
at least 1500 octets. 
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A summary of the Maximum-Receive-Unit Configuration Option format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 

(O 20 3 425.20" PS C95 O 2340 6 7 48 OOF LU O A Or he 87 9000: L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Maximum-Receive-Unit 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


Length 


Maximum-Receive-Unit 


The Maximum-Receive-Unit field is two octets, and specifies the 
maximum number of octets in the Information and Padding fields. 
It does not include the framing, Protocol field, FCS, nor any 
transparency bits or bytes. 


6.2 Async-Control-Character-Map 
Description 


This Configuration Option provides a method to negotiate the use 
of control character transparency on asynchronous links. 


For asynchronous links, the default value is Oxffffffff, which 
causes all octets less than 0x20 to be mapped into an appropriate 
two octet sequence. For most other links, the default value is 0, 
since there is no need for mapping. 


However, it is rarely necessary to map all control characters, and 
often it is unnecessary to map any control characters. The 
Configuration Option is used to inform the peer which control 
characters MUST remain mapped when the peer sends them. 


The peer MAY still send any other octets in mapped format, if it 
is necessary because of constraints known to the peer. The peer 
SHOULD Configure-Nak with the logical union of the sets of mapped 
octets, so that when such octets are spuriously introduced they 
can be ignored on receipt. 
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A summary of the Async-Control-Character-Map Configuration Option 
format is shown below. The fields are transmitted from left to 
right. 


0 1 2 3 
01234567890Ŷā12345678901234567890 1 
PA A A A A A A A A A A A A A A A A A A A A A o o o o o 

| Type | Length | Async-Control-Character-Map 
PA A 4-4-4 4-4-4 A A papi pip pip papi papi gigi o o gigi o o 
| ACCM (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


Length 


Async-Control-Character-Map 


The Async-Control-Character-Map field is four octets and indicates 
the set of control characters to be mapped. The map is sent most 
Significant octet first. 


Each numbered bit corresponds to the octet of the same value. If 
the bit is cleared to zero, then that octet need not be mapped. 

If the bit is set to one, then that octet MUST remain mapped. For 
example, if bit 19 is set to zero, then the ASCII control 
character 19 (DC3, Control-S) MAY be sent in the clear. 


Note: The least significant bit of the least significant octet 
(the final octet transmitted) is numbered bit 0, and would map 
to the ASCII control character NUL. 
6.3 Authentication-Protocol 
Description 

On some links it may be desirable to require a peer to 

authenticate itself before allowing network-layer protocol packets 

to be exchanged. 

This Configuration Option provides a method to negotiate the use 


of a specific authentication protocol. By default, authentication 
is not required. 
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An implementation MUST NOT include multiple Authentication- 
Protocol Configuration Options in its Configure-Request packets. 
Instead, it SHOULD attempt to configure the most desirable 
protocol first. If that protocol is Configure-Nak’d, then the 
implementation SHOULD attempt the next most desirable protocol in 
the next Configure-Request. 


If an implementation sends a Configure-Ack with this Configuration 
Option, then it is agreeing to authenticate with the specified 
protocol. An implementation receiving a Configure-Ack with this 
Configuration Option SHOULD expect the peer to authenticate with 
the acknowledged protocol. 


There is no requirement that authentication be full duplex or that 
the same protocol be used in both directions. It is perfectly 
acceptable for different protocols to be used in each direction. 
This will, of course, depend on the specific protocols negotiated. 


A summary of the Authentication-Protocol Configuration Option format 
is shown below. The fields are transmitted from left to right. 


0 1 2 3 
OPT 2-3 45:01 Sf 809009 AW 2. BARS 6 8 0 OAL, 2 9. 445. 06: 80 9 001. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A o A A A ++ 

| Type | Length | Authentication-Protocol 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 
| Data 

+-+-+-+-+ 


Type 


Authentication-Protocol 


The Authentication-Protocol field is two octets and indicates the 
authentication protocol desired. Values for this field are always 
the same as the PPP Protocol field values for that same 
authentication protocol. 


Up-to-date values of the Authentication-Protocol field are 


specified in the most recent "Assigned Numbers" RFC [2]. Current 
values are assigned as follows: 


Simpson [Page 44] 


RFC 1548 The Point-to-Point Protocol December 1993 


Value (in hex) Protocol 

c023 Password Authentication Protocol 

e223 Challenge Handshake Authentication Protocol 
Data 


The Data field is zero or more octets and contains additional data 
as determined by the particular protocol. 


6.4 Quality-Protocol 
Description 


On some links it may be desirable to determine when, and how 
often, the link is dropping data. This process is called link 
quality monitoring. 


This Configuration Option provides a method to negotiate the use 
of a specific protocol for link quality monitoring. By default, 
link quality monitoring is disabled. 


There is no requirement that quality monitoring be full duplex or 
that the same protocol be used in both directions. It is 
perfectly acceptable for different protocols to be used in each 
direction. This will, of course, depend on the specific protocols 
negotiated. 


A summary of the Quality-Protocol Configuration Option format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 
OA LA O LL A ARS OL A 67 O. TL 
AA A A A A A A A A A A A A A A A A A A O dd dd o ++ 


| Type | Length | Quality-Protocol 
E 
| Data 


+-+-+-+-+ 


Type 
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Quality-Protocol 


The Quality-Protocol field is two octets and indicates the link 
quality monitoring protocol desired. Values for this field are 
always the same as the PPP Protocol field values for that same 

monitoring protocol. 


Up-to-date values of the Quality-Protocol field are specified in 
the most recent "Assigned Numbers" REC [2]. Current values are 
assigned as follows: 


Value (in hex) Protocol 
c025 Link Quality Report 
Data 


The Data field is zero or more octets and contains additional data 
as determined by the particular protocol. 


6.5 Magic-Number 
Description 


This Configuration Option provides a method to detect looped-back 
links and other Data Link Layer anomalies. This Configuration 
Option MAY be required by some other Configuration Options such as 
the Quality-Protocol Configuration Option. By default, the 
Magic-Number is not negotiated, and zero is inserted where a 
Magic-Number might otherwise be used. 


Before this Configuration Option is requested, an implementation 
MUST choose its Magic-Number. It is recommended that the Magic- 
Number be chosen in the most random manner possible in order to 
guarantee with very high probability that an implementation will 
arrive at a unique number. A good way to choose a unique random 
number is to start with an unique seed. Suggested sources of 
uniqueness include machine serial numbers, other network hardware 
addresses, time-of-day clocks, etc. Particularly good random 
number seeds are precise measurements of the inter-arrival time of 
physical events such as packet reception on other connected 
networks, server response time, or the typing rate of a human 
user. It is also suggested that as many sources as possible be 
used simultaneously. 


When a Configure-Request is received with a Magic-Number 


Configuration Option, the received Magic-Number is compared with 
the Magic-Number of the last Configure-Request sent to the peer. 
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If the two Magic-Numbers are different, then the link is not 
looped-back, and the Magic-Number SHOULD be acknowledged. If the 
two Magic-Numbers are equal, then it is possible, but not certain, 
that the link is looped-back and that this Configure-Request is 
actually the one last sent. To determine this, a Configure-Nak 
MUST be sent specifying a different Magic-Number value. A new 
Configure-Request SHOULD NOT be sent to the peer until normal 
processing would cause it to be sent (that is, until a Configure- 
Nak is received or the Restart timer runs out). 


Reception of a Configure-Nak with a Magic-Number different from 
that of the last Configure-Nak sent to the peer proves that a link 
is not looped-back, and indicates a unique Magic-Number. If the 
Magic-Number is equal to the one sent in the last Configure-Nak, 
the possibility of a looped-back link is increased, and a new 
Magic-Number MUST be chosen. In either case, a new Configure- 
Request SHOULD be sent with the new Magic-Number. 


If the link is indeed looped-back, this sequence (transmit 
Configure-Request, receive Configure-Request, transmit Configure- 
Nak, receive Configure-Nak) will repeat over and over again. If 
the link is not looped-back, this sequence might occur a few 
times, but it is extremely unlikely to occur repeatedly. More 
likely, the Magic-Numbers chosen at either end will quickly 
diverge, terminating the sequence. The following table shows the 
probability of collisions assuming that both ends of the link 
select Magic-Numbers with a perfectly uniform distribution: 


Number of Collisions Probability 
1 1/2**32 2.3 E-10 
2 1/2**32**2 = 5.4 E-20 
3 1/2**32**3 = 1.3 E-29 


Good sources of uniqueness or randomness are required for this 
divergence to occur. If a good source of uniqueness cannot be 
found, it is recommended that this Configuration Option not be 
enabled; Configure-Requests with the option SHOULD NOT be 
transmitted and any Magic-Number Configuration Options which the 
peer sends SHOULD be either acknowledged or rejected. In this 
case, loop-backs cannot be reliably detected by the 
implementation, although they may still be detectable by the peer. 


If an implementation does transmit a Configure-Request with a 
Magic-Number Configuration Option, then it MUST NOT respond with a 
Configure-Reject if it receives a Configure-Request with a Magic- 
Number Configuration Option. That is, if an implementation 
desires to use Magic Numbers, then it MUST also allow its peer to 
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do so. If an implementation does receive a Configure-Reject in 
response to a Configure-Request, it can only mean that the link is 
not looped-back, and that its peer will not be using Magic- 
Numbers. In this case, an implementation SHOULD act as if the 
negotiation had been successful (as if it had instead received a 
Configure-Ack). 


The Magic-Number also may be used to detect looped-back links 
during normal operation as well as during Configuration Option 
negotiation. All LCP Echo-Request, Echo-Reply, and Discard- 
Request packets have a Magic-Number field. If Magic-Number has 
been successfully negotiated, an implementation MUST transmit 
these packets with the Magic-Number field set to its negotiated 
Magic-Number. 


The Magic-Number field of these packets SHOULD be inspected on 
reception. All received Magic-Number fields MUST be equal to 
either zero or the peer's unique Magic-Number, depending on 
whether or not the peer negotiated a Magic-Number. Reception of a 
Magic-Number field equal to the negotiated local Magic-Number 
indicates a looped-back link. Reception of a Magic- Number other 
than the negotiated local Magic-Number or the peer's negotiated 
Magic-Number, or zero if the peer didn’t negotiate one, indicates 
a link which has been (mis)configured for communications with a 
different peer. 


Procedures for recovery from either case are unspecified and may 
vary from implementation to implementation. A somewhat 
pessimistic procedure is to assume a LCP Down event. A further 
Open event will begin the process of re-establishing the link, 
which can't complete until the loop-back condition is terminated 
and Magic-Numbers are successfully negotiated. A more optimistic 
procedure (in the case of a loop-back) is to begin transmitting 
LCP Echo-Request packets until an appropriate Echo-Reply is 
received, indicating a termination of the loop-back condition. 


A summary of the Magic-Number Configuration Option format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 

0 TERA DB 9 0 LA DnE T g IMAZ A: 809: 0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Magic-Number 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Magic-Number (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Type 


Length 


Magic-Number 


The Magic-Number field is four octets and indicates a number which 
is very likely to be unique to one end of the link. A Magic- 
Number of zero is illegal and MUST always be Nak’d, if it is not 
Rejected outright. 


6.6 Protocol-Field-Compression 
Description 
This Configuration Option provides a method to negotiate the 
compression of the PPP Protocol field. By default, all 


implementations MUST transmit packets with two octet PPP Protocol 
fields. 


PPP Protocol field numbers are chosen such that some values may be 
compressed into a single octet form which is clearly 
distinguishable from the two octet form. This Configuration 
Option is sent to inform the peer that the implementation can 
receive such single octet Protocol fields. 


As previously mentioned, the Protocol field uses an extension 
mechanism consistent with the ISO 3309 extension mechanism for the 
Address field; the Least Significant Bit (LSB) of each octet is 
used to indicate extension of the Protocol field. A binary "0" as 
the LSB indicates that the Protocol field continues with the 
following octet. The presence of a binary "1" as the LSB marks 
the last octet of the Protocol field. Notice that any number of 
"0" octets may be prepended to the field, and will still indicate 
the same value (consider the two binary representations for 3, 
00000011 and 00000000 00000011). 


When using low speed links, it is desirable to conserve bandwidth 
by sending as little redundant data as possible. The Protocol- 
Field-Compression Configuration Option allows a trade-off between 
implementation simplicity and bandwidth efficiency. If 
successfully negotiated, the ISO 3309 extension mechanism may be 
used to compress the Protocol field to one octet instead of two. 
The large majority of packets are compressible since data 
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protocols are typically assigned with Protocol field values less 
than 256. 


Compressed Protocol fields MUST NOT be transmitted unless this 
Configuration Option has been negotiated. When negotiated, PPP 
implementations MUST accept PPP packets with either double-octet 
or single-octet Protocol fields, and MUST NOT distinguish between 
them. 


The Protocol field is never compressed when sending any LCP 
packet. This rule guarantees unambiguous recognition of LCP 
packets. 


When a Protocol field is compressed, the Data Link Layer FCS field 
is calculated on the compressed frame, not the original 
uncompressed frame. 


A summary of the Protocol-Field-Compression Configuration Option 
format is shown below. The fields are transmitted from left to 


right. 
0 1 
Qu 2 3 dh 26. le o 9.0 D2. BA 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 
7 
Length 
2 


6.7 Address-and-Control-Field-Compression 
Description 


This Configuration Option provides a method to negotiate the 
compression of the Data Link Layer Address and Control fields. By 
default, all implementations MUST transmit frames with Address and 
Control fields appropriate to the link framing. 


Since these fields usually have constant values for point-to-point 
links, they are easily compressed. This Configuration Option is 
sent to inform the peer that the implementation can receive 
compressed Address and Control fields. 
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If a compressed frame is received when Address-and-Control-Field- 
Compression has not been negotiated, the implementation MAY 
silently discard the frame. 


The Address and Control fields MUST NOT be compressed when sending 
any LCP packet. This rule guarantees unambiguous recognition of 


LCP packets. 


When the Address and Control fields are compressed, the Data Link 
Layer FCS field is calculated on the compressed frame, not the 
original uncompressed frame. 


A summary of the Address-and-Control-Field-Compression configuration 
option format is shown below. The fields are transmitted from left 


to right. 
0 1 
0.1.2 30d 0720 9-28" 9770" 0.223, AS 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 
8 
Length 
2 


A. LCP Recommended Options 
The following Configurations Options are recommended: 
SYNC LINES 


Magic Number Link Quality Monitoring No Address and Control Field 
Compression No Protocol Field Compression 


ASYNC LINES 


Async Control Character Map Magic Number Address and Control Field 
Compression Protocol Field Compression 


Security Considerations 


Security issues are briefly discussed in sections concerning the 
Authentication Phase, the Close event, and the Authentication- 
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Protocol Configuration Option. Further discussion is in a companion 


document entitled PPP Authentication Protocols. 
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